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Proposal for Modifying Linking 


We plan to modify the link jsys in TENEX to work in a little bit 
better way in terms of the user interface. Conversations with BBN 
indicate that they have no complaints with the current 
implementation. However, if after we have gained experience with our 
new implementation, we will let them know about it and they will 
review the new implementation and possibly accept it as part of 
standard TENEX. 


I would appreciate feedback in the next couple of days so that I can 
go ahead and implement this proposal (or a modified proposal or 
nothing...). (I estimate that it will only take a couple of hours to 
implement!) 


(Note that by modifying the jsys, the proposed changes as specified 
will be in effect at the user level in the exec.) 


The default state for all users will remain as it currently is, i.e. 
RECEIVE LINKS. 


Now, consider users A, B, and C. 
If A and B link to each other they are now holding a conversation. 


After establishing a conversation, all members of the conversation 
will be placed in the REFUSE LINKS state. 


If user C (or any other user) now tries to link to user A (or B), the 
bell will ring on users A (or B) and C terminals indicating that A 
(or B) is in a REFUSE LINKS state. 


If A ignores the bell then C is not admitted to the conversation 
and A and B can continue their conversation as if C had never 
tried to enter the conversation. 


However, if A does a RECEIVE LINKS while the bell is ringing (the 
bell rings for approximately 15 seconds), then C will be linked 
into the conversation and not to just user A. Thus A and B will 
be linked, A and C will be linked, and B and C will be linked, 
i.e., a three way conversation. Also, users A, B, and C will be 
in the REFUSE LINKS state. 
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Whenever a user leaves a conversation, his state will be set 
automatically to RECEIVE LINKS. 


Thus, when user C does a break links the resulting states will be: 
A and B will be linked and both will be in REFUSE LINKS 
C will be out of the conversation and will be in RECEIVE LINKS 


Now, when A or B does a BREAK LINKS there will no longer be a 
conversation and both A and B will be in the RECEIVE LINKS state. 


To summarize: 


After any conversation is established, all members of the 
conversation are placed in the REFUSED LINKS state. 


When a user links to a terminal or a user, he is in fact linking 
into a conversation if one exists or to an individual if no 
conversation is taking place. 


When a user leaves a conversation, she is placed in the RECEIVE 
LINKS state. 


Changes to the TLINK jsys will be necessary to implement the above. 
No changes are required in the EXEC. In addition to the above 
changes, we will add a new jsys that will return the link and advise 
status for a passed terminal, i.e., you will be able to tell which 
lines are linked to the passed terminal, which lines the passed 
terminal is linked to, which line the passed terminal is advising, 
and/or which line is advising the passed terminal. This information 
will probably be incorporated into the systat printout, the where is 
printout, and will probably be used within NLS for shared screen 
work. 
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